3.6. Client Access Throttling Policies
At times, clients consume
server resources to the point where everyone is affected. For example,
some third-party search programs can send a large number of RPC
requests when they perform indexing. The sheer number of RPC requests
from these clients can cause performance problems on the backend.
Exchange 2010 uses client-throttling
policies to prevent this situation. A default client-throttling policy
is configured when the Exchange organization is created. The default
policy can be customized or additional policies can be created. The
default policy settings are shown in Table 4.
Do not make changes directly to the default policies—create a copy of
the default and make the changes to the new policy. This will enable an
administrator to quickly revert back to defaults if the need arises.
Table 4. Default Client-Throttling Policy Settings
| PROPERTY | SETTING | COMMENT |
|---|
| EASMaxConcurrency | 10 | The number of concurrent connections an ActiveSync user can have running concurrently. |
| EWSMaxConcurrency | 10 | The number of concurrent connections an Exchange Web Services user can have running concurrently. |
| EWSFastSearchTimeoutInSeconds | 60 | The length of time, in seconds, searches made by EWS run before timing out. |
| OWAMaxConcurrency | 5 | The number of concurrent connections an Outlook Web App user can have running concurrently. |
| POPMaxConcurrency | 20 | The number of concurrent connections a POP3 user can have running concurrently. |
| PowerShellMaxConcurrency | 18 | For
Remote Windows PowerShell users, the number of remote Windows
PowerShell concurrent sessions. For Exchange Web Services, the number
of concurrent cmdlet executions that a user can have at the same time. |
| RCAMaxConcurrency | 20 | The number of concurrent connections an RPC Client Access user can have running concurrently. |
| CPUStartPercent | 75 | The per-process CPU percentage at which users begin to be backed off. |
Note: It
is a best practice to make sure that no throttling policy parameters
are set to $null (no limit). This prevents users from unintentionally
placing a high load on the server.
|
Robin Thomas
Program Manager, Exchange Mailbox, Microsoft Corporation
Soon after Exchange 2010 was released, customers who used RIM BlackBerry Enterprise Server (BES) discovered that BlackBerry devices may experience some issues caused by the new throttling
functionality. For example, users who made a change to calendar items,
such as deleting an appointment, would not have that change replicated
to Exchange. Also, if a BlackBerry user was sent a meeting invite, it
would not show up on the device. To fix this issue, you need to disable
client throttling. Although disabling throttling completely will
certainly fix the problem, you are giving up a lot of protection from
this new feature. A better solution is to create a new policy and
assign it only to the BES service account. You can create and apply the
appropriate throttling policy for the BES service account by typing
these two commands into EMS.
New-ThrottlingPolicy
BES –RCAMaxConcurrency $null -RCAPercentTimeInCAS $null
–RCAPercentTimeInMailboxRPC $null –RCAPercentTimeInAD $null Set-Mailbox BESAdmin –ThrottlingPolicy BES
BES is the name of the throttling policy and can be anything. BESAdmin is the BES service account.
At this point, you can run Get-ThrottlingPolicy BES to see the details. BES servers access Exchange using RpcClientAccess service, so the only values that are relevant here are RCA*.
For Exchange 2010 RTM,
a second configuration change is required for BlackBerry Enterprise
Servers to work correctly. In Exchange 2010 SP1 and later, this
configuration is covered via the previously-mentioned throttling
policy. By default, Exchange only allows 50 concurrent address book
connections. The BES account makes lookups on behalf of the users, so
you may exhaust this connection limit very quickly. RIM recommends
changing the MaxSessionsPerUser
value to 100,000 (this is located in the
microsoft.exchange.addressbook.service.exe.config file). Unfortunately,
unlike the throttling policy, you cannot configure this setting per
user, so it will raise the limit for all users. You may want to start
with a smaller number and increase as your number of BlackBerry devices
increases.
For more information, visit RIM's Web site for configuring the BlackBerry Enterprise Server with Exchange 2010 help document: http://docs.blackberry.com/en/admin/deliverables/12070/Configuring_Exchange_2010_environ_962756_11.jsp.
|
Service Pack 1 includes several improvements for client throttling.
In RTM code, the client that has been throttled will end up with failed
requests. This can result in poor user experience. Take, for example,
an Entourage client that is syncing a mailbox and is constantly going
over budget. Any other user requests, such as a name resolution, will
also fail. In Service Pack 1, however, instead of failing requests, the
request is added to an asynchronous queue that will delay processing.
This sleep time is equal to a backoff time plus 1 millisecond. At the
time of this writing, the backoff time had not been finalized. For
batch operations, processing will pause until the caller has regained 1
millisecond of budget. Then, processing will continue starting with the
item left off, and it will stream the items back to the caller as they
are processed.
3.7. MailTips
MailTips is a very useful new feature that will make a lot of users happy. It is important to first understand the feature before we look at the mechanics and performance impact of turning it on.
How many times have you sent
an e-mail only to receive an out-of-office notification? MailTips
provides feedback while composing a message, before you hit send. Figure 11 shows an example of an e-mail with two informational messages. MailTips lets the user know that he is sending mail to a distribution
list that has a large number of members. Also, Jeffrey is out of the
office, so the user may want to send the message to one of Jeffrey's
peers.
Keep in mind that
MailTips is not a security measure, meaning that is does not prevent
users from taking action. Rather, the MailTips feature only provides
useful information to help users make better decisions before hitting
Send. There are a number of prebuilt MailTips, as listed in Table 5.
Table 5. Exchange 2010 MailTips
| MAILTIP | DESCRIPTION | DATA SOURCE | AVAILABLE OFFLINE |
|---|
| Invalid Internal Recipient | Informs the user that a user does not exist for an e-mail address within the organization. | Active Directory | No |
| Mailbox Full | A recipient has a full mailbox. | Mailbox Store | No |
| Automatic Replies | A recipient has an automatic reply enabled (such as out-of-office). | Mailbox Store | No |
| Custom | A recipient has a custom MailTip enabled. | Active Directory | Yes |
| Restricted Recipient | A recipient has a mail delivery restriction configured. | Mailbox Store | No |
| External Recipients | A recipient is external or part of a distribution list. | Group Metrics | Yes |
| Large Audience | A distribution list contains more than 25 members (configurable). | Group Metrics | Yes |
| Moderated Recipient | A recipient is enabled for moderation. |
| Yes |
| Reply-All on BCC | The user replies all to a message on which he or she was bcc'd. |
|
|
| Oversize Message | The
message is larger than the organizational limit, maximum send size on
the user's mailbox, maximum receive size on the recipient's mailbox, or
maximum request length setting for OWA. |
| Yes |
MailTips are triggered by the mail client during one of the following operations:
MailTips
processing occurs in a background thread, so it will not impact the
user working with their message. In other words, users do not have to
wait for MailTips to finish processing before they send a message, if that is what they want to do.
Figure 12 provides a deeper look at the MailTips architecture. The source for MailTips data comes from Active Directory, Exchange Mailbox Server, and Group Metrics data.
The Groups Metrics process is responsible for collecting and recording information about the size of distribution lists and external recipients. This information is used for the external recipient and large audience MailTips.
Groups Metrics generation
happens by default on the Mailbox server that is responsible for
creating the OAB and can be assigned to another Mailbox server, which
is important
in a large organization. On Sunday, a full generation runs for every
group (both static and dynamic) within a random time two hours from
midnight. Each day, the process will generate incremental results. The
day for full generation is hard-coded, but the generation time can be
set using the set-mailboxserver property named GroupMetricsGenerationTime (24-hour format). If you change the GroupMetricsGenerationTime
property, the next generation occurs according to the old schedule.
Subsequent generations will start at the new time. You can force
regeneration by restarting the Microsoft Exchange Service Host service
or rebooting the server. The process creates files by default in the
<Exchange_Install_Path>\GroupMetrics. The files created are shown
in Table 6.
Table 6. GroupMetrics Files
| FILENAME | DESCRIPTION |
|---|
| GroupMetrics-<date>T<time>.bin | Binary file containing the membership and external members count |
| GroupMetrics-<servername>.xml | XML file containing information about the Group Metrics generation server |
| ChangedGroups.txt | Plaintext file containing the list of groups that were updated since the last time Group Metrics was run |
Every eight hours, the Microsoft Exchange File Distribution
Service on the Client Access server builds a list of Mailbox servers
that have Group Metrics generation enabled. By default, the
organizational configuration setting for Group Metrics is enabled. This
means that Group Metrics will be generated on every mailbox server that
generates an OAB and will also generate Group
Metrics data and be included in the list. In addition, the list
includes mailbox servers that are explicitly enabled for GroupMetrics
generation. The property GroupMetricsGenerationEnabled
is used to manually enable generation for a Mailbox server and is set
to false by default. After the list is created, the Client Access
server will pull the Group Metrics data from the best server. The best
server is based on Active Directory sites and link costs. One option is
to leave GroupMetricsGenerationEnabled
set to false and let the Client Access server use the OAB topology.
This is one less topology that needs to be designed and maintained. For
organizations that do not use OABs or need more control, the option
still exists to create your own topology.
To support offline clients, the OAB was extended to have MailTips data. Table 5 lists which MailTips are available offline.
The process for evaluating MailTips is shown in Figure 13.
The mail client makes a request to the local Client Access server.
The Client Access server retrieves data from Active Directory and reads the Group Metrics data (locally).
For local recipients in the message header, the Client Access server queries the Mailbox server.
For each remote recipient, the Client Access server makes a request to the remote recipient's Client Access server.
The remote Client Access server makes RPC requests for data from the remote Mailbox server.
The remote Client Access server returns MailTips information about the remote recipients to the local Client Access server.
The Client Access server returns the MailTips information back to the client.
To limit performance impact, you
should be aware of a few constraints. First, only messages with less
than 200 recipients will be evaluated for MailTips. Second, individuals in a distribution
group are not separately evaluated. Finally, the MailTips for Automatic
Replies and Mailbox Full are reevaluated every two hours for draft
messages that are left open for extended periods when being composed.
This ensures a user has fresh information when they leave a message
open for a long period of time.
